Field
Aspects of the present disclosure generally relate to an authorization server, a control method, and a storage medium for verifying an access authority to data.
Description of the Related Art
In recent years, the use of what is called a cloud service, which has been developed on the Internet, has been expanding. Various cloud services have individually released their application programming interfaces (APIs) of web services, so that the function provided by a service is enabled to be used by another application or cloud service via the API. In these web service APIs, the employment of a standard protocol called “OAuth 2.0” for implementing cooperation regarding authorization has been promoted. Japanese Patent Application Laid-Open No. 2017-027459 discusses an invention using OAuth 2.0.
According to OAuth 2.0, for example, an API that acquires data of a user managed by a service A is allowed to be accessed by a service B within a range permitted by the user. At this time, the service A is supposed to obtain an explicit authorization of the user with respect to an access to the API by the service B while specifying a range that is accessed by the service B. Explicitly performing authorization by the user is referred to as an “authorization operation”. The range that is accessed is referred to as a “scope” in the case of OAuth 2.0, and the permissible amount of access to data is determined by the scope.
When the user performs an authorization operation, the service B receives a token that certifies that an access to data in the range permitted by the user in the service A has been allowed (hereinafter referred to as an “authorization token”), so that a subsequent access to the API of the service A can be implemented by using the authorization token. The authorization operation of the user to authorize the service B to access the resource of the user is referred to as “authority transfer”.
Protocols that allow authority transfer can lack the flexibility to adapt to a change in resource in the service and a change in authority of the user. For example, an authorization token in OAuth 2.0 allows authority transfer only with respect to a scope confirmed when the user performs an authorization operation. Therefore, in a case where there is a change in the scope with respect to which the user is allowed to perform authority transfer or there is an increase or decrease or a change in the scope that is adapted to use an API, the user can be forced to re-perform an authorization operation in order to use the API, so that convenience may be impaired.
As described above, since the range of a resource that is accessed by a terminal, i.e., a scope that defines the range for using a service, and the authority of a user may change, authority transfer protocols including OAuth 2.0 are required to have flexibility. First, changes of the scope and the authority of a user are described.
In the field of enterprises, the authority possessed by a user can vary depending on the position of the user. For example, the authority possessed by a user can differ between the position to access information including specific secrets of a company and the position not to access such information, and a scope and an authority possessed by the user in OAuth 2.0 are in a close relationship with each other. In other words, an authority to allow access to a scope that indicates the range of a resource in a service is defined, and an operation for assigning the authority to a particular user is presumed. Since the position of a user can change due to a change in the role of the user in the company or a change in the task thereof, the authority of the user can change on a case-by-case basis due to various factors. In other words, the authority of the user at a certain point of time can differ from the authority of the user at a later point of time, so that the range of a scope with respect to which the user is able to perform authority transfer to a service can vary.
With respect to a cloud service, a method or architecture for implementing the release of new functions at intervals of a short period, called “continuous integration”, “continuous delivery”, or “continuous deployment”, is attracting attention. Then, performing the release of new functions at intervals of a short period is expected to further expand due to the provision of various tools, developmental processes, and design approaches. Performing the release at intervals of a short period means that an increase of APIs of web services or an expansion of the range or a change of the range of data that is handled by the specific API is performed at intervals of a short period.
In summary, a change in the scope with respect to which the user is able to perform authority transfer due to a change in the authority of the user, an increase or decrease in scopes due to the release at a short cycle, and a change in the definition of a scope are supposed to be performed. In a case where such situation has occurred, authority transfer has been performed, and an authorization token has been issued, the user is required to re-perform an authorization operation to cause an authorization token that adapts to a change in the authority of the user and/or a change in the scope to be issued.
What is needed is enabling operation of an authorization token that adapts to a change in the authority of the user and/or a change in the scope while saving the trouble of the authorization operation and enhancing convenience.